网络架构

2015-11-15

架构, 网络

名词术语

远程调用相关

SOA，Webservice，SOAP，REST，RPC，RMI，JMS的区别与联系

http://blog.csdn.net/pcceo1/article/details/51245249

SOA面向服务的软件架构（Service Oriented Architecture）

是一种计算机软件的设计模式，主要应用于不通应用组件中通过某种协议来互操作

它的基本设计原理是：服务提供了一个简单的接口，抽象了底层的复杂性，然后用户可以访问独立的服务，而不需要去了解服务底层平台实现。

正因为SOA架构实现不依赖于技术，因此能够被各种不同的技术实现。
```
因此REST、SOAP、RPC、RMI、DCOM等都是SOA的一种实现而已。
```
RPC（Remote Procedure Call Protocol）

RPC使用C/S方式，采用http协议,发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，通常形成“classname.methodname”形式，这就向RPC服务器表明，被请求的方法在为“classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

RPC 不支持对象的概念，传送到 RPC 服务的消息由外部数据表示 (External Data Representation, XDR) 语言表示，这种语言抽象了字节序类和数据类型结构之间的差异。只有由 XDR 定义的数据类型才能被传递， RPC 不允许传递对象。优点是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，无法在编译器检查错误，只能在运行期检查。
Web Service

Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。

Web Service主要涉及的概念:
```
1. Http传输信道
2. XML的数据格式
3. SOAP封装格式
4. WSDL的描述方式
5. UDDI  UDDI是一种目录服务，企业可以使用它对Webservices进行注册和搜索
```
webservice是一种标准，他可以通过soap或rest的方式来实现。
SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。

事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。
RMI （Remote Method Invocation）

RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于Java语言，客户机与服务器紧耦合。
JMS（Java Messaging Service）

JMS是Java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS支持两种消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。

负载均衡

http://www.cnblogs.com/itfly8/p/5043435.html

作用

解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；
提供故障转移，实现高可用；
通过添加或减少服务器数量，提供网站伸缩性（扩展性）；
安全防护；（负载均衡设备上做一些过滤，黑白名单等处理）

分类

DNS负载均衡

在DNS服务器，配置多个A记录，这些A记录对应的服务器构成集群

大型网站总是部分使用DNS解析，作为第一级负载均衡。

优点

使用简单：负载均衡工作，交给DNS服务器处理，省掉了负载均衡服务器维护的麻烦
提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能；

缺点

可用性差：DNS解析是多级解析，新增/修改DNS后，解析时间较长；解析过程中，用户访问网站将失败；
扩展性低：DNS负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展；
维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）

实践建议

将DNS作为第一级负载均衡，A记录对应着内部负载均衡的IP地址，通过内部负载均衡将请求分发到真实的Web服务器上。
一般用于互联网公司，复杂的业务系统不合适使用。

IP负载均衡

在网络层通过修改请求目标地址进行负载均衡。

优点：

在内核进程完成数据分发，比在应用层分发性能更好；

缺点：

所有请求响应都需要经过负载均衡服务器，集群最大吞吐量受限于负载均衡服务器网卡带宽；

链路层负载均衡

在通信协议的数据链路层修改mac地址，进行负载均衡。

实际处理服务器ip和数据请求目的ip一致，不需要经过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式（DR模式）。

优点：性能好；

缺点：配置复杂；

实践建议：DR模式是目前使用最广泛的一种负载均衡方式。

混合型负载均衡

方式一

动静分离的场景，反向代理服务器（集群）可以起到缓存和动态请求分发的作用，当时静态资源缓存在代理服务器时，则直接返回到浏览器。如果动态页面则请求后面的应用负载均衡（应用集群）。

方式二

适合动态请求场景。

算法

轮询

将所有请求，依次分发到每台服务器上，适合服务器硬件同相同的场景。

优点：服务器请求数目相同；

缺点：服务器压力不一样，不适合服务器配置不同的情况；
随机

请求随机分配到各个服务器。

优点：使用简单；

缺点：不适合机器配置不同的场景；
最少链接

将请求分配到连接数最少的服务器（目前处理请求最少的服务器）。

优点：根据服务器当前的请求处理情况，动态分配；

缺点：算法实现相对复杂，需要监控服务器请求连接数；
Hash（源地址散列）

根据IP地址进行Hash计算，得到IP地址。

优点：将来自同一IP地址的请求，同一会话期内，转发到相同的服务器；实现会话粘滞。

缺点：目标服务器宕机后，会话会丢失；
加权

在轮询，随机，最少链接，Hash’等算法的基础上，通过加权的方式，进行负载服务器分配。

优点：根据权重，调节转发服务器的请求数目；

缺点：使用相对复杂；

硬件负载均衡

采用硬件的方式实现负载均衡，一般是单独的负载均衡服务器，价格昂贵，一般土豪级公司可以考虑，业界领先的有两款，F5和A10。

主要考虑一下几个方面：

（1）功能考虑：功能全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡；

（2）性能考虑：一般软件负载均衡支持到5万级并发已经很困难了，硬件负载均衡可以支持

（3）稳定性：商用硬件负载均衡，经过了良好的严格的测试，从经过大规模使用，在稳定性方面高；

（4）安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙，防DDOS攻击等安全功能；

（5）维护角度：提供良好的维护管理界面，售后服务和技术支持；

（6）土豪公司：F5 Big Ip 价格：15w~55w不等；A10 价格：55w-100w不等；

缺点

（1）价格昂贵；

（2）扩展能力差；

软件负载均衡

Ngnix负载均衡

是一款轻量级的Web服务器/反向代理服务器

并发性能：

官方支持每秒5万并发，实际国内一般到每秒2万并发，有优化到每秒10万并发的。
三万并发连接下，10个Nginx进程，消耗内存150M。
淘宝tengine团队测试结果是“24G内存机器上，处理并发请求可达200万”。

特点：

1.模块化设计：良好的扩展性，可以通过模块方式进行功能扩展。
2.高可靠性：主控进程和worker是同步实现的，一个worker出现问题，会立刻启动另一个worker。
3.内存消耗低：一万个长连接（keep-alive）,仅消耗2.5MB内存。
4.支持热部署：不用停止服务器，实现更新配置文件，更换日志文件、更新服务器程序版本。
5.并发能力强：官方数据每秒支持5万并发；
6.功能丰富：优秀的反向代理功能和灵活的负载均衡策略

功能：

支持静态资源的web服务器。
http,smtp,pop3协议的反向代理服务器、缓存、负载均衡；
支持FASTCGI（fpm）
支持模块化，过滤器（让文本可以实现压缩，节约带宽）,ssl及图像大小调整。
内置的健康检查功能
基于名称和ip的虚拟主机
定制访问日志
支持平滑升级
支持KEEPALIVE
支持url rewrite
支持路径别名
支持基于IP和用户名的访问控制。
支持传输速率限制，支持并发数限制。

均衡策略：

加权轮询（weighted round robin）
ip hash策略
fair策略
通用hash
一致性hash

Ngnix高可用：

至少包含两个Ngnix服务器，一台主服务器，一台备服务器，之间使用Keepalived做健康监控和故障检测。
开放VIP端口，通过防火墙进行外部映射。DNS解析公网的IP实际为VIP。

LVS负载均衡

由毕业于国防科技大学的章文嵩博士于1998年5月创立

并发性能：

默认4096，可以修改但需要重新编译。

功能：

实现IP层（网络层）负载均衡

LVS/NAT方式的负载均衡集群
    Director机器收到外界请求，改写数据包的目标地址，按相应的调度算法将其发送到相应Real Server上，Real Server处理完该请求后，将结果数据包返回到其默认网关，即Director机器上，Director机器再改写数据包的源地址，最后将其返回给外界。
    当用户的请求非常短，而服务器的回应非常大的情况下，会对Director形成很大压力，成为新的瓶颈，从而使整个系统的性能受到限制。

LVS/TUN方式的负载均衡集群
    Director机器收到外界请求，按相应的调度算法,通过IP隧道发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户。
    后端的Real Server必须是支持IP Tunneling的操作系统。

LVS/DR方式的负载均衡集群
    Director机器收到外界请求，按相应的调度算法将其直接发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户
    LVS/DR需要改写请求报文的MAC地址，所以所有服务器必须在同一物理网段内。

架构：

Load Balancer层：
    位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。

Server Array层：
    由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。

Shared Storage层：
    是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数 据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。

均衡策略：

    1.轮询调度（Round Robin）

    调度器通过“轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

    2.加权轮询（Weighted Round Robin）

    调度器通过“加权轮询”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

    3.最少链接（Least Connections）

    调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。

    4.加权最少链接（Weighted Least Connections）

    在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

    5.基于局部性的最少链接（Locality-Based Least Connections）

    “基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。

    6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

    “带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

    7.目标地址散列（Destination Hashing）

    “目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

    8.源地址散列（Source Hashing）

    “源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

场景:

    一般作为入口负载均衡或内部负载均衡，结合反向代理服务器使用。

HaProxy负载均衡

特点:

支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
配置简单，支持url检测后端服务器状态；
做负载均衡软件使用，在高并发情况下，处理速度高于nginx；
TCP层多用于Mysql从（读）服务器负载均衡。 （对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡）
能够补充Nginx的一些缺点比如Session的保持，Cookie引导等工作

均衡策略:

roundrobin：轮询，轮流分配到后端服务器；
static-rr：根据后端服务器性能分配；
leastconn：最小连接者优先处理；
source：根据请求源IP，与Nginx的IP_Hash类似。

短视频所面临的架构问题

https://www.toutiao.com/i6240712819407323649/

数据大小的差异

10s 的视频大小 1MB 多，而一条 5 分钟视频的美拍甚至要达到几十 M

如何上传、如何存放、以及如何播放的问题。弱网环境要上传，上传的成功率会比较低，晚高峰的时候，省际网络的拥塞情况下，要更为明显得多

针对上传，需要基于 CDN 走动态加速来优化网络链路

对于比较大的视频需要做好分片上传，减少失败重传的成本和失败概率等来提升可用性

同时不同 CDN 厂商的链路状况在不同的运营商不同地区可能表现不一，所以也需要结合基调测试，选择一些比较适合自己的 CDN 厂商链路

视频容量级别也达到 PB 级别的规模，所以要求存储本身能够具备比较强的线性扩展能力，并且有足够的资源冗余。可以通过自建的服务（对于数据隐私性和安全性要求比较高的场景）或者云存储服务来解决。

播放方面
```
对于 60s，300s 的视频，需要考虑到文件比较大，同时有拖动的需求，所以一般使用 http range 的方式，或者基于 HLS 的点播播放方式，不过这种需要单独的转码支持。
短视频更多使用 http range 的方式。
播放时卡顿的问题，这种一般通过网络链路优化；或者通过多码率的自适应优化，比如多路转码，然后根据特定算法模型量化用户网络情况进行选码率，网络差的用低码率的方式。
```
数据的格式标准差异

H.264、H.265 等，有着比较固定和通用的一些格式标准。

数据的处理需求

数据处理需求，比如水印、帧缩略图、转码等。而视频处理的操作是非常慢的，会带来巨大的资源开销。

主要分为两块：

客户端处理，视频处理尽量往客户端靠，利用现有强大的手机处理性能来减少服务器压力。客户端的视频编解码方式，会有软编码和硬编码的方式

服务端的处理，主要是进行视频的一些审核转码工作，也有一些抽帧生成截图的工作等，目前使用 ffmpeg 进行一些处理。转码服务集群本身需要具备可弹性伸缩和异步化消峰机制，以便来适应这种突增请求的场景。

为支持亿级用户，架构所做的一些改进

挑战

性能的挑战
可用性的挑战
突发热点的挑战
业务频繁迭代的挑战

基于分层的token架构设计

按照场景可以划分token的类别

原始账号密码类别

用户名和密码
APPKEY 和APPSercret

会话类别

浏览器端TOKEN
APP端TOKEN
API端TOKEN

接口调用类别

API端TOKEN

身份授权类别

PC和移动端相互授权的token

token的层级关系

原始账号密码类别

    广义的 账号/密码 有如下的呈现方式:

        传统的注册用户名和密码
        应用程序的app_id/app_key

会话类别

    充当着session的角色，不同的客户端有不同的生命周期

    用户使用账号密码，换取会话token
    Web平台生存周期短
    移动端生存周期长

接口调用类别

    功能：服务端应用程序api接口访问和调用的凭证。
    使用具有较长生命周期的会话token来换取此接口访问token。
    在客户端token之下还加上一个access_token， 主要是为了让具有不同生命周期的客户端token最后在调用api的时候， 能够具有统一的认证方式

身份授权类别

    pam_token
    由已经登录和认证的PC端生成的二维码的原始串号（Pc Auth Mobile）
    主要步骤如下：

        1、PC上用户已经完成认证，登录了系统

        2、PC端生成一组和此用户相关联的pam_token

        3、PC端将此pam_token的使用链接生成二维码

        4、移动端扫码后，请求服务器，并和用户信息关联

        5、移动端获取refresh_token(长时效的会话)

        6、根据 refresh_token 获取 access_token

        7、完成正常的接口调用工作

    备注:

        生存周期为2分钟,2分钟后过期删除
        没有被使用时,每1分钟变一次
        被使用后,立刻删除掉
        此种认证模式一般不会被使用到

    map_token
    由已经登录的移动app来扫码认证PC端系统，并完成PC端系统的登录（Mobile Auth Pc）。

    主要步骤：

        1、移动端完成用户身份的认证登录app

        2、未登录的PC生成匿名的 map_token

        3、移动端扫码后在db中生成 map_token 和用户关联（完成签名）

        4、db同时针对此用户生成 web_token

        5、PC端一直以 map_token 为参数查找此命名用户的 web_token

        6、PC端根据 web_token 去获取 access_token

        7、后续正常的调用接口调用工作

    备注:

        生存周期为2分钟,2分钟后过期删除
        没有被使用时,每1分钟变一次
        被使用后,立刻删除掉

技术架构

名词术语

远程调用相关

负载均衡

短视频所面临的架构问题

基于分层的token架构设计